1. Field of the Invention
This invention pertains in general to computer graphics and in particular to a texture loading pipeline in a three-dimensional graphics system.
2. Background Art
Texture mapping has become a very common feature in computer systems such as game consoles, personal computers, and high-end workstations. Traditionally, texture mapping is used to add realism to computer graphics images without increasing the amount of geometry necessary to produce the images.
The concept of texture mapping is relatively simple: stretch an arbitrary image and paste it onto a three-dimensional (3-D) geometry. Mapping the texture to the 3-D geometry consists of computing, for each picture element (pixel) in the final image, the corresponding texture element (texel) in the texture image. There are many different techniques for performing this computation. In general, each of the techniques treats each pixel as a surface that has a corresponding surface in the texture image. The texture surface covered by a given pixel can contain an arbitrary, and not necessarily integer, number of texels of different colors. Each pixel, however, can have only one color. Usually, the color of the pixel is determined by taking multiple samples from the texture and filtering the samples at different stages of the rendering to derive the appropriate color.
When the textures are large, it is difficult to sample and filter the texture at the rate needed to rapidly draw 3-D scenes from changing perspectives. Specialized computer systems with large memories and fast graphics pipelines can use a brute force approach to process large textures at rates necessary to support the scene changes. However, dedicated hardware is often prohibitively costly and cannot be used in mass market platforms.
A common technique for overcoming this hurdle and dealing with large textures is a xe2x80x9cmipmap.xe2x80x9d A mipmap is a storage technique that stores a texture at multiple levels of resolution. A mipmap resembles an inverted pyramid. The top of the mipmap represents the largest texture having the highest amount of detail. Each level below the top has a resolution a power of two smaller than the previous level, and holds that much less detail. For example, if the top mipmap level of a two dimensional texture holds 64 texels, the immediately lower level has 16 texels. Subsequent levels hold four and one texel.
When a mipmapped texture is mapped on a polygon, the mipmap level that corresponds most closely to the size of the polygon is used. For example, if the polygon is a square having four pixels on a side, the mipmap level having 16 texels will be mapped onto the polygon. In effect, the mipmap reduces hardware demands by performing the image processing and filtering (i.e., scales down the texture to fit the polygon) ahead of time.
Storing a mipmap requires only ⅓ more memory than storing the original texture. However, storing even this much more data creates a problem. Textures must be stored in fast memory in order to meet the needs of renderer. The fastest systems use special memory for texture storage while slower systems use the fast video memory in the display buffer for texture memory. Textures can easily be too large to fit in these memories. For example, a texture representing North America at 25 meter resolution occupies more than 200 gigabytes of memory.
One solution to this problem is to subdivide the geometry. For example, a texture representing North America can be divided into four areas, which, in turn, can be subdivided into smaller areas. The texture can be divided and subdivided in the same manner as the geometry into smaller textures called xe2x80x9ctiles.xe2x80x9d Since the tiles are smaller than the original texture, the tiles can be stored, manipulated, and processed at the rate necessary to support 3-D rendering. Tiling, however, creates visible artifacts in the rendered scene, such as seams at the edges of the tiles. It may be possible to eliminate the artifacts from one viewpoint in the final image, but not from all possible viewpoints. Another disadvantage of tiling is that a complex database must be used to store the tiles and substantial processing time is required to regenerate the tiles whenever the texture is modified. Further, tiling requires that the underlying geometry be divided on the texture boundaries such that edges of the texture tiles match the edges of the geometry tiles, thereby making both automatic and real-time geometric reconstruction of underlying surfaces extremely difficult.
Another problem with mipmaps is that the large source texture might be composed of many smaller textures linked together. Some of textures might be from different sources and, therefore, have different resolutions (i.e., texels per unit of coordinate space). For example, a texture map of a large area, such as North America, might use low-resolution sources for textures of less populated areas and high-resolution sources for textures of more populated areas. Mipmaps do not provide a general way to represent the different resolutions of the textures. The fixed requirement that levels be separated by powers of two limit the use of mipmaps in this regard.
Accordingly, there is a need for a way to represent, store, and process texture data in a way that supports real-time 3-D rendering. The solution to this need should support the use of large textures and textures having differing resolutions and coordinate spaces.
The above needs are met by a texture loading pipeline that operates on a source texture having one or more levels of detail. Each level of detail (LOD) represents a rectangular subset of a particular region of the source texture at a particular resolution. There can be arbitrary relationships between the regions and resolutions represented by particular levels of detail. Thus, the source texture can be sparse and different levels of detail can represent different regions of the source texture at different resolutions.
Preferably, there are multiple instances of the texture loading pipeline, with each instance corresponding to one of the levels of detail in the source texture. The texture for a LOD is preferably subdivided into tiles and stored in a storage space. The storage space can be local to the computer system executing the texture loading pipeline and/or remote from the computer system. For example, the storage space can be located on a hard drive or CD-ROM attached to the computer system and/or in communication with the computer system through a network. The texture tiles can be compressed or uncompressed.
Texture tiles are retrieved from the storage space by an asynchronous request queue and stored in a tile cache. Compressed texture tiles are preferably stored in a compressed tile cache. An asynchronous decompression queue decompresses the texture tiles in the compressed tile cache and stores the decompressed tiles in a decompressed tile cache.
Textures in the region of interest are paged from the tile cache into a texture cache. The texture cache is preferably located in a high-speed memory, such as a dedicated texture memory in a graphics adapter. The textures in the region of interest, i.e., the region of the global coordinate space for which textures are requested, are preferably selected for paging via toroidal roaming. In toroidal roaming, an arbitrary rectangle, or other bounding shape, specifies the textures in the tile cache to page into the texture cache. The rectangle moves as the region of interest changes. Texels that leave the region of interest are deleted from the texture cache, texels that enter the region of interest are paged into the texture cache, and texels remaining in the region of interest are left in the texture cache.
By definition, the size of the region of interest is bounded by the resolution of the display 118. The resolution of the display, refresh rate, and color depth of the textures, therefore, also define an upper bound on the rate of data, or bandwidth, required to update the texture cache. The real bandwidth, however, is often lower than the upper bound because there is usually spatial coherency between adjacent frames. Toroidal roaming exploits this coherency to reduce the needed bandwidth. It is apparent that a pipeline for a lower-resolution LOD can support an effectively higher bandwidth through the original image than a higher-resolution pipeline since the lower-resolution pipeline needs less texture paging in response to most changes in the region of interest.
A pipeline driver outputs the region of interest to the tile cache and the region of interest, a maximum resolution cutoff, and an update time to the texture cache. The maximum resolution cutoff preferably specifies the highest LOD for which the textures in the region of interest should be cached. Pipelines that cannot meet the rate of data flow given the change in the region of interest are preferably cut off since no benefit would be gained by executing those pipelines.
The update time input specifies the amount of processing time available to each pipeline. The majority of processing time is preferably devoted to the pipeline for the highest resolution LOD that can meet the rate of data flow given the change in the region of interest. Some processing time is also preferably devoted to the pipelines for the lower levels of detail in case the optimal pipeline fails to meet the needed rate of data flow.
At the end of certain update periods, the textures are bound to a geometry in order to render a 3-D scene. To perform this task, a texture selector selects among the texture caches of the different pipelines for the cache having the best complete set of textures. The selected textures are transformed by a hardware texture matrix from the arbitrary local coordinate space to the global coordinate space. Then, the textures are simply xe2x80x9cboundxe2x80x9d and used to render on geometry using a simple texture coordinate specification. For the rest of the system, this collection of pipelines acts as a single large mipmapped texture with a single coordinate system. The specific operations of the underlying pipelines are invisible to the rest of the system.
Accordingly, the present invention allows arbitrarily large textures to be represented as a single texture with a single coordinate system. The rendering system xe2x80x9cthinksxe2x80x9d of this texture as xe2x80x9cjust another texture.xe2x80x9d Also, since the underlying caching mechanisms are multi-level asynchronous look-ahead caches, a fixed amount of bandwidth-bounded and directly proportional to screen resolution-can be used to represent a texture of arbitrary size.